Communication protocols that use control plane signalling between network nodes to establish data plane connections, such as X.25, X.76, and Private Network-to-Network Interface (PNNI), generally provide procedures for releasing connections on detection of a protocol failure. If a particular node has a restart of its control plane, for example, then its neighbor node control plane will detect the restart by detecting a period of receiving no messages from the restarting control plane on a signalling link.
Existing protocols indicate that the procedures for such a NO_RESPONSE event are to release calls and thus disconnect the data plane connections associated with a restarting control plane. However, in many implementations, there is separation between the control and data planes. A failure of the control plane thus does not always imply that the data plane has also failed. Disconnecting a data plane connection in this case causes an unnecessary interruption in end user data flow. If a call that originates or terminates in a node affected by a control plane restart is torn down by a neighbor node, then the data path cannot re-establish until the control plane has fully restarted and the signalling links have returned to an ‘up’ state.
Some Internet Protocol (IP) switches support a procedure whereby “Hello” packets are continuously broadcast between neighbor switches. Each switch restarts a hold timer when it receives a “Hello” packet. Normally, if the hold timer expires, a switch assumes that its neighbor switch's control plane has failed and will remove the neighbor from its routing tables and stop forwarding packets to that neighbor. According to a modified restart procedure, a switch that detects a control plane restart at a neighbor switch will continue to route packets to the neighbor switch throughout the control plane outage. When the restarting neighbor switch's control plane resets and broadcasts another “Hello” packet, the switch will re-send routing information to the neighbor switch.
However, this IP restart procedure relies entirely on a restarting switch's neighbor switches to provide all required routing information to the restarting switch. This may be undesirable in that in some cases not all required information may be available at the neighbor switches, for instance.
In addition, existing techniques are generally provided on a per-interface basis, for all or no connections that use the same interface. These techniques therefore do not provide for connection-level selectivity for enabling such procedures.
Thus, there remains a need for improved techniques for handling controller failures such as control plane restarts.